-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Verification Formula Simplification #5026
Conversation
bench: 1492957
Hm, I'm a bit reluctant to see this as a simplification. |
I'm also thinking along the lines of @pb00067 this is not really simplifying the logic here. NMP is using a |
I have some concerns about the logic in master for
It would be probably more robust to have something like the bellow to prevent it from becoming negative |
That's ok for me, if this PR get closed, I will try again the removal of the *3/4 parameter in the formula, as cj also suggested in Discord. However, one important thing that I learned while diving into this, is that the zugzwang test suite that we have is not very useful if you just run it blindly because:
So running an engine through the test suite reporting only the number of final solutions found given by the GUI is not a good practice. |
because it's mathematically prof: so we have 6 + 16/3 + 4 |
Makes sense, probably the tune going from 14 to 15 to 16 helped you in proving this :P |
to point 1: to point 2: to point 3: |
|
I do also think that two tunes going from 14 to 15 to 16 have helped passing those VLTC tunes
|
which parameter are talking about, that changed with time from 14 to 15 to 16 ? |
Which means do not do verification search for depth < 16 and return the null move search value immediatly. |
Yes, that one. No hard feelings, but I think this parameter should be left out in tuning sessions, |
Simplifying the verification formula, which was added in order to better detect zugzwang positions.
Passed STC:
LLR: 2.93 (-2.94,2.94) <-1.75,0.25>
Total: 60160 W: 15529 L: 15336 D: 29295
Ptnml(0-2): 241, 6702, 16005, 6887, 245
https://tests.stockfishchess.org/tests/view/65b78dffc865510db027530e
Passed LTC:
LLR: 2.94 (-2.94,2.94) <-1.75,0.25>
Total: 159414 W: 39970 L: 39891 D: 79553
Ptnml(0-2): 95, 17369, 44694, 17460, 89
https://tests.stockfishchess.org/tests/view/65b80835c865510db0275b73
Benchmark with zugzwang-suite (see #1338 ), single core, max 45 secs per position:
Patch solves 31 out of 37 - (After the study that follows changed to 32 out of 37)
Master solves 32 out of 37
However, there is alot to be said about this epd suite after I studied it and our master and this patch interaction with it.
Below are the important notes that I was able to deduct.
Position #17: Both variations were able to solve it, but tbh master solved it much quicker than patch.
Position #18 : None of the two variations were able to solve it
Position #19 : None of the two variations were able to solve it
Position #21 : The epd solution here is wrong, as it states that Ke3 and Kd3 are both valid solutions, but in reality, only Kd3 leads to white to win, while Ke3 leads only to draw, and by the way both master and patch didn't see the win, master opted for Ke3 with eval of 0.00 and patch opted for Nc3 also with eval 0.00, but none of them was able to see that Kd3 wins (And epd should be adjusted to remove Ke3 as a valid solution)
Position #28 : Both variations saw the win, but both of them opted to waste two extra plys with a repetition, opting for Nc3+ Kb4 Nd5+ Ka4, and then going for the valid solution with f4, and to be honest I don't see anything wrong with it, as long as the win was foreseen.
Position #33 : Both variations similarly opted for Kd7, which similarly to position 28, also leads to a win, but with a few extra plys, and both of them get stuck for a long time when analyzing this position (@peregrineshahin so, since you are investigating this SF issue, you can also use this position as testing material)
Position #36: Both engines similarly opted for Kb2, with fail high evaluations, and tbh even though I didn't do a deep study, I have the feeling that also here the epd solutions are not correct, as they only give Kb3 and Rf5 as valid solutions, but based on a quick check, it seems that also Kb2 is a valid solution after all.
Anyway in conclusion, I didn't observe huge differences in zugzwang detection for the proposed patch, the only two negative points I observed were:
Files:
Analyses.log
Analyses.txt